Files that changed from the base of the PR and between a8802d6 and 8760c33.

• examples/notebooks/edtf-support.ipynb (1 hunks)
• src/undate/init.py (1 hunks)
• src/undate/dateformat/edtf/edtf.lark (3 hunks)
• src/undate/dateformat/edtf/formatter.py (1 hunks)
• src/undate/dateformat/edtf/transformer.py (1 hunks)
• src/undate/undate.py (2 hunks)
• tests/test_dateformat/edtf/test_edtf_parser.py (2 hunks)
• tests/test_dateformat/edtf/test_edtf_transformer.py (2 hunks)
• tests/test_dateformat/test_edtf.py (2 hunks)

tests/test_dateformat/edtf/test_edtf_parser.py (1)

Line range hint 16-40: Verify test cases against EDTF specification.

Let's verify that the test cases align with the EDTF specification documentation.

✅ Verification successful

Let me check the content of the found files to verify the test cases against the specification.

---

Let me check the actual EDTF parser implementation to verify the test cases.

---

Let me check the actual parser implementation and test file content.

---

Let me check the EDTF grammar file to complete the verification.

---

Based on the comprehensive review of the EDTF implementation, grammar, tests, and example notebook, I can now provide the final response.

Test cases align with EDTF specification levels 0, 1, and 2

The test cases in test_edtf_parser.py are well-aligned with the EDTF specification as evidenced by:

• Level 0 features:

  • Basic dates (e.g., "1984", "1984-05", "1984-12")
  • Time intervals (e.g., "1000/2000", "1000-01/2000-05-01")

• Level 1 features:

  • Letter-prefixed years (e.g., "Y170000002", "-Y170000002")
  • Negative years (e.g., "-1985")
  • Qualifiers (e.g., "1984?", "2004-06~", "2004-06-11%")
  • Unspecified digits (e.g., "201X", "20XX")
  • Extended intervals (e.g., "1985-04-12/..", "../1985-04-12")

• Level 2 features:

  • Partial unspecified (e.g., "156X-12-25", "1XXX-12")
  • Masked precision (e.g., "1984-1X")

The implementation is validated by both unit tests and the comprehensive example notebook edtf-support.ipynb which demonstrates parsing and formatting for each EDTF feature.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for EDTF specification documentation or examples
echo "Searching for EDTF specification references..."
rg -l "EDTF" --type md
rg -l "Extended Date.*Time Format" --type md

# Look for any existing EDTF validation or example files
echo "Searching for EDTF example files..."
fd -e md -e txt -e rst -e ipynb . | rg -i "edtf|date.*format"

Length of output: 381

---

Script:

#!/bin/bash
# Check CHANGELOG.md for EDTF specification references
echo "=== CHANGELOG.md EDTF references ==="
rg -A 5 -B 5 "EDTF|Extended Date.*Time Format" CHANGELOG.md

# Check the example notebook
echo -e "\n=== EDTF examples from notebook ==="
cat examples/notebooks/edtf-support.ipynb | jq -r '.cells[] | select(.cell_type == "markdown" or .cell_type == "code") | .source[]' | grep -A 10 -B 10 "EDTF"

# Look for EDTF parser implementation to understand supported features
echo -e "\n=== EDTF parser implementation ==="
rg -l "class.*EDTFParser" 

Length of output: 17249

---

Script:

#!/bin/bash
# Search for EDTF parser file
echo "=== Finding EDTF parser file ==="
fd -e py | rg -i "edtf.*parser"

# Look at the parser implementation
echo -e "\n=== EDTF parser implementation ==="
rg -A 10 "class.*EDTFParser" --type py

# Check for EDTF grammar or patterns
echo -e "\n=== EDTF patterns ==="
rg "EDTF.*pattern" --type py -A 5

Length of output: 413

---

Script:

#!/bin/bash
# Check the EDTF parser implementation
echo "=== EDTF Parser Implementation ==="
cat src/undate/dateformat/edtf/parser.py

# Check the test file content
echo -e "\n=== EDTF Parser Tests ==="
cat tests/test_dateformat/edtf/test_edtf_parser.py

Length of output: 2224

---

Script:

#!/bin/bash
# Check the EDTF grammar file
echo "=== EDTF Grammar ==="
cat src/undate/dateformat/edtf/edtf.lark

# Check if there are any other EDTF-related files
echo -e "\n=== Other EDTF files ==="
fd . | rg -i "edtf"

Length of output: 2624

src/undate/dateformat/edtf/edtf.lark (4)

3-3: LGTM: Added SIGNED_INT import for negative year support.

The addition of SIGNED_INT import is appropriate for supporting negative year values in the grammar.

---

38-40: LGTM: Well-structured unspecified digit support.

The implementation of unspecified digits using 'X' follows the EDTF Level 2 specification correctly. The rules are well-documented and properly structured.

---

46-46: Verify handling of boundary cases for five-digit years.

The pattern /-?Y\d{5,}/ correctly supports negative years, but let's verify the handling of boundary cases.

Let's check the test coverage for five-digit years:

#!/bin/bash
# Search for test cases involving five-digit years
rg -A 3 "Y\d{5}" tests/
# Search for negative five-digit year tests
rg -A 3 "-Y\d{5}" tests/

---

18-20: Verify handling of extreme negative years.

The switch to SIGNED_INT for year values is correct. However, we should verify the handling of edge cases.

Let's check if there are any tests or validation for extreme negative years:

✅ Verification successful

Let me search for more specific test patterns and validation logic to verify the handling of extreme negative years.

---

Based on the search results, I can now generate the final response as we have found evidence of boundary handling for extreme years in the codebase.

Extreme negative years are properly handled with defined boundaries

The codebase implements explicit boundaries for year values:

• Minimum year limit is set to -2.5e16
• Maximum year limit is set to 2.5e16
• The implementation includes proper handling of year validation through min_year/max_year logic

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for test cases involving negative years
rg -l "test.*negative.*year|test.*year.*negative" tests/
# Search for actual negative year test values
rg -A 2 "-\d{1,}.*year" tests/

Length of output: 2205

---

Script:

#!/bin/bash
# Search for test cases and validation logic related to negative years
rg -e "test.*negative.*year" -e "test.*year.*negative" -e "-\d+.*year" tests/ -A 3

# Search for any validation or boundary checks on year values
ast-grep --pattern 'if $_ < $_' 
ast-grep --pattern 'if $_ > $_'

# Look for any year-related constants or limits
rg -e "MIN.*YEAR|MAX.*YEAR|YEAR.*MIN|YEAR.*MAX" -e "year.*limit" -i

Length of output: 1762

src/undate/dateformat/edtf/transformer.py (1)

69-78: Verify handling of edge cases.

Let's ensure the implementation handles various edge cases correctly.

✅ Verification successful

Edge cases for year parsing are properly handled

The code's handling of edge cases for year parsing has been verified through the test suite and implementation:

• Negative years are correctly handled (e.g., "-Y17000002", "-1985")
• Large years with 5+ digits are supported (e.g., "Y17000002")
• The implementation properly:
  • Detects negative years with startswith("-")
  • Strips the "Y" prefix for extended year format
  • Preserves the sign in the final integer conversion

The test files (particularly tests/test_dateformat/edtf/test_edtf_transformer.py and tests/test_dateformat/edtf/test_edtf_parser.py) demonstrate comprehensive coverage of these edge cases.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for test cases covering edge cases in year parsing
# Expected: Tests for various year formats including -Y00000, Y00000, -Y99999

# Look for test cases in the test files
rg -A 5 "year_fivedigitsplus|test.*negative.*year" tests/

Length of output: 59

---

Script:

#!/bin/bash
# Let's try a broader search for test files and test cases related to year parsing
# First, find test files related to EDTF date parsing
fd "test.*\.py" tests/ --exec rg -l "edtf|date|year"

# Then search for specific test cases with year values
rg -A 5 "test.*year|Y\d{5}|-Y\d{4}|negative.*year" tests/

Length of output: 5238

---

Script:

#!/bin/bash
# Let's also check the implementation file for any validation or edge case handling
rg -A 10 "def.*year|parse.*year|Y\d{5}|-Y\d{4}" src/

Length of output: 4947

---

Script:

#!/bin/bash
# Search for any error handling or validation patterns around year parsing
ast-grep --pattern 'try {
  $$$
  year = $$$
  $$$
}'

ast-grep --pattern 'if $COND {
  $$$
  year = $$$
  $$$
}'

Length of output: 116

tests/test_dateformat/test_edtf.py (3)

16-20: LGTM! Improved test reliability for unknown dates.

The change to use string comparison instead of direct object comparison is a good approach, as it correctly handles the semantics of unknown dates. The comments clearly explain the rationale.

---

27-27: LGTM! Simplified assertion reflects better EDTF understanding.

The removal of the questioning comment and simplified assertion shows confidence in the EDTF support implementation.

---

53-57: Verify alignment with EDTF Level 2 specification.

The test cases for unspecified digits look comprehensive. Let's verify they align with the official EDTF specification.

✅ Verification successful

Let me gather more specific information about the EDTF Level 2 implementation and specification details.

---

Let me check the actual implementation details of the EDTF format handling to verify the test cases.

---

Based on the implementation details and test cases shown, I can now generate the final response.

Test cases correctly implement EDTF Level 2 unspecified digit patterns

The test cases align with EDTF Level 2 specification for unspecified digits:

• Supports partial unspecified year digits (e.g., "156X")
• Allows fully unspecified years ("XXXX")
• Handles unspecified month digits (e.g., "1XXX-XX")
• Supports unspecified day components
• Implementation correctly converts between internal representation and EDTF format

The implementation in EDTFDateFormat class properly handles the conversion using EDTF_UNSPECIFIED_DIGIT constant and maintains the format specification requirements.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for EDTF specification references in documentation or comments
rg -i "edtf.*level.*2|extended.*date.*time.*format.*level.*2" --type md --type txt

# Look for any existing level 2 feature documentation
fd -e md -e rst -e txt -e py | xargs rg "unspecified.*digits"

Length of output: 633

---

Script:

#!/bin/bash
# Check the parser implementation for unspecified digits
ast-grep --pattern 'def parse_unspecified_digits($$$)'

# Look for EDTF specification or documentation comments
rg -B 3 -A 10 "level 2 unspecified digits"

# Check the transformer implementation
ast-grep --pattern 'def transform_unspecified_digits($$$)'

# Look for any documentation about EDTF format support
fd README -e md | xargs rg -i "edtf"

Length of output: 3177

---

Script:

#!/bin/bash
# Check the EDTF format implementation
rg -l "class.*EDTFDateFormat" | xargs cat

# Look for unspecified digit handling in the implementation
rg -B 2 -A 5 "def.*to_string" src/

# Check for any EDTF specification references in comments
rg -B 2 -A 5 "EDTF.*Level.*2|Extended.*Date.*Time.*Format.*Level.*2" -i

Length of output: 9700

src/undate/dateformat/edtf/formatter.py (1)

56-62: LGTM! The negative year handling looks correct.

The implementation correctly handles the EDTF specification requirement for years with more than 4 digits while properly preserving the negative sign. The logic appropriately:

1. Excludes the minus sign when counting digits
2. Preserves the negative sign in the final output
3. Adds the 'Y' prefix as required by the EDTF spec

Let's verify the handling of various year formats:

✅ Verification successful

The negative year handling implementation is well-tested and correctly follows EDTF specification

The test files show comprehensive coverage for the negative year handling:

• Test cases explicitly verify formatting of large years: "Y17000002" and "-Y17000002"
• Negative year tests include both regular 4-digit years ("-1985") and extended years
• The test_to_string method in TestEDTFDateFormat specifically verifies:
  • Undate(17000002) → "Y17000002"
  • Undate(-17000002) → "-Y17000002"
  • Undate(-1985) → "-1985"

The implementation correctly handles all test cases and follows the EDTF specification requirements for both regular and extended year formats.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the test coverage for various year formats
# Expected: Find test cases covering negative years and years > 4 digits

# Test: Search for relevant test cases
rg -A 5 "test.*year" "tests/test_dateformat/test_edtf.py"

# Test: Check if there are any existing EDTF examples in documentation
fd -g "*.md" -x rg -l "EDTF.*year"

Length of output: 94

---

Script:

#!/bin/bash
# Let's try a different approach to find test cases and examples

# Search for test files related to EDTF
fd -g "test_edtf*.py" -x cat {}

# Search for any year-related patterns in test files
rg -l "Y\d{5,}|-\d{4,}" tests/

# Look for EDTF formatter test class and its methods
ast-grep --pattern 'class Test$_EDTF {
  $$$
}'

# Check the actual formatter implementation for context
cat src/undate/dateformat/edtf/formatter.py

Length of output: 9540

src/undate/undate.py (2)

57-59: LGTM: Special case handling for unknown year.

The implementation correctly handles "XXXX" as an unknown year according to EDTF specification.

---

Line range hint 116-122: Verify the robustness of max day calculation.

The logic for calculating the maximum day has been improved to handle unknown years, but there are a few considerations:

1. Using a non-leap year constant (self.NON_LEAP_YEAR) for unknown years means February will always be calculated as 28 days.
2. The fallback to 31 days could be too permissive for some months.

Let's verify the impact of this change on date calculations:

Consider enhancing the logic to handle leap years more accurately:

 elif year is None and month:
-    # If we don't have year and month,
-    # calculate based on a known non-leap year
-    # (better than just setting 31, but still not great)
-    _, max_day = monthrange(self.NON_LEAP_YEAR, max_month)
+    # For unknown years, use the maximum possible days for the month
+    # For February, this means 29 days to account for leap years
+    if max_month == 2:
+        max_day = 29
+    else:
+        _, max_day = monthrange(self.NON_LEAP_YEAR, max_month)

examples/notebooks/edtf-support.ipynb (1)

773-789: Consider documenting Python version requirements.

The notebook uses Python 3.13.0, which is a very recent version. Consider:

• Documenting minimum Python version requirements
• Testing compatibility with older Python versions (e.g., 3.8+)
• Adding version checks in the code